Automatic value distribution in decentralized protocols

ABSTRACT

Example methods and systems are directed to performing value distribution in a self-sustaining manner in the context of a decentralized finance protocol. One or more self-executing contracts are deployed to a blockchain network to cause association of an asset pool with a plurality of asset providers. One or more of the asset providers stake pool tokens against the asset pool. The one or more self-executing contracts cause tracking of performance of the asset pool in a sliding time window by applying a predetermined performance metric. A weight of the asset pool is automatically updated by applying a predetermined weight metric that is based on the performance of the asset pool. The one or more self-executing contracts perform value distribution to the asset pool based on the weight of the asset pool.

CLAIM OF PRIORITY

This application claims the benefit of priority to U.S. ProvisionalApplication Ser. No. 63/396,047, filed on Aug. 8, 2022, which isincorporated herein by reference in its entirety.

TECHNICAL FIELD

Subject matter disclosed herein generally relates to blockchaintechnology. More specifically, but not exclusively, the subject matterherein includes methods and systems for automatically performing valuedistribution to asset pools used in decentralized protocols, such asdecentralized finance protocols.

BACKGROUND

A decentralized finance protocol, often referred to as a “DeFiprotocol,” includes formats, codes, or procedures governing the use ofdigital assets on a blockchain network. A DeFi protocol often needsliquidity to function effectively. However, users may be unlikely todeposit assets in a DeFi protocol without sufficient incentives. Yieldfarming is a technique that is used to incentivize users to depositassets on a DeFi protocol, e.g., to provide liquidity to an asset pool.In exchange for depositing assets, a user may receive pool tokensrepresenting their share of the assets in a pool. These pool tokens canthen be staked, e.g., by depositing them into “farms,” making a usereligible for value distribution. In some cases, value distributionincludes issuing rewards, such as governance tokens that provideprotocol voting rights.

However, integrating yield farming into a DeFi protocol may result in anumber of technical challenges. For example, a significant degree ofmanual input or control may be required in the value distributionprocess, e.g., to manage or issue rewards. In some cases, developers mayneed to allocate rewards manually, creating a potential point of systemfailure, e.g., if developers miss an update. Manual value distributionor allocation also introduces the possibility of subjectivity, bias, oreven unscrupulous activity. Further, a DeFi protocol may distributevalue in such a manner that top performing asset pools receive adisproportionate share of value, and thus a disproportionate share ofcontrol over the DeFi protocol itself This may create a negative,self-feeding cycle in which a small subset of users govern importantaspects such as reward distribution, in turn reducing transparency,asset security, or broad adoption of the DeFi protocol.

BRIEF DESCRIPTION OF THE DRAWINGS

Some embodiments are illustrated by way of example and not limitation inthe figures of the accompanying drawings. In the drawings, which are notnecessarily drawn to scale, like numerals may describe similarcomponents in different views. To easily identify the discussion of anyparticular element or act, the most significant digit or digits in areference number refer to the figure number in which that element isfirst introduced. Some non-limiting examples are illustrated in thefigures of the accompanying drawings in which:

FIG. 1 is a block diagram illustrating various layers of a DeFi system,according to some examples.

FIG. 2 is a diagrammatic representation of a networked computingenvironment suitable for deploying self-executing contracts andproviding a DeFi protocol interface, according to some examples.

FIG. 3 is a diagrammatic representation of the deployment of a pluralityof self-executing contracts to a blockchain network to distribute valuein a DeFi protocol, according to some examples.

FIG. 4 is a diagrammatic representation of users interacting with aplurality of asset pools of a DeFi protocol on a blockchain network,according to some examples.

FIG. 5 is a flowchart illustrating a method suitable for deployingself-executing contracts to a blockchain network to register, track theperformance of, and perform value distribution to asset pools of a DeFiprotocol, according to some examples.

FIG. 6 is a flowchart illustrating a method suitable for facilitatinguser interaction with an asset pool of a DeFi protocol, according tosome examples.

FIG. 7 is a block diagram showing a software architecture for acomputing device, according to some examples.

FIG. 8 is a block diagram of a machine in the form of a computer system,according to some examples, within which instructions may be executedfor causing the machine to perform any one or more of the methodologiesdiscussed herein.

DETAILED DESCRIPTION

Examples disclosed herein provide methods and systems that enable orfacilitate yield farming. Example systems disclosed herein aredecentralized, tamper-proof, and self-balancing. Techniques aredescribed to provide enhanced inclusivity of asset pools of a DeFiprotocol in the context of value distribution without requiring manualintervention, e.g., from developers or interface providers, subsequentto deployment.

The term “blockchain network,” as used herein, refers to a digital,decentralized, and distributed system, network, or configuration ofsystems, in which data is stored in multiple records (e.g., “blocks”)that are cryptographically linked to each other. Each record or blockmay contain a list of transactions or other forms of data records, andmay be connected to each other through a cryptographic hash function,thus forming a chain. A blockchain network may comprise a singleblockchain structure, or multiple, interrelated blockchain systems,e.g., interconnected blockchains, sidechains, or child chains. Ablockchain network may include public, private, or hybrid blockchains.

A blockchain network may provide a digital ledger of transactions thatis duplicated and distributed across a network of computer systems.Blockchain networks may utilize different consensus mechanisms tovalidate and verify transactions or data blocks, such as Proof-of-Work(PoW), Proof-of-Stake (PoS), or Delegated Proof-of-Stake (DPoS). Ablockchain network accommodates the use of self-executing contracts(e.g., “smart contracts”), DeFi protocols, decentralized applications(“dApps”), non-fungible tokens, blockchain-based data storage, or otherapplications, services, or tools that are deployable on a blockchain.

DeFi protocols have shown potential to change the financial industry byproviding decentralized technology. DeFi protocols typically rely onself-executing contracts to perform transactions directly on ablockchain network, thus removing the traditional requirement of anintermediary. A DeFi protocol may provide a Decentralized Exchange(DEX). A DEX is a platform that allows users to trade digital assetswithout the need for an intermediary. Examples of DeFi protocols includeAave™, yEarn™, Uniswap™, Synthetix™, and Compound™.

DeFi protocols typically require liquidity to operate as intended, andmany DeFi protocols incentivize users to deposit liquidity or otherassets on a DeFi protocol. A user that deposits or invests assets inthis manner is referred to herein as an “asset provider.” It is notedthat an asset provider may be a human user, a non-human user (e.g., a“bot”), or a combination thereof.

Examples described herein address or alleviate the technical challengesreferred to above by providing an autonomous system (e.g., a yieldfarming system) that can manage asset pools and value distribution,e.g., issuing of rewards, in a self-sustaining manner. According to someexamples, one or more self-executing contracts are deployed on ablockchain network to cause association of an asset pool with aplurality of asset providers. The blockchain network may be used toimplement a DeFi protocol, e.g., the blockchain network is theunderlying blockchain on which the DeFi protocol operates. The pooltokens may represent respective shares of the plurality of assetproviders in the asset pool.

One or more of the asset providers may stake pool tokens against theasset pool. The one or more self-executing contracts cause tracking ofperformance of the asset pool in a sliding time window by applying apredetermined performance metric. The sliding time window may have apredetermined duration, e.g., 7 days, 14 days, 21 days, or 30 days. Aweight of the asset pool is automatically updated by applying apredetermined weight metric that is based on the performance of theasset pool. In some examples, a system may include only one asset pool.In other examples, a system may include a plurality of asset pools. Inthe latter case, performance of the asset pool may be determined orassessed relative to performance of one or more other asset pools.

Performance may be tracked within the sliding time window. The one ormore self-executing contracts perform value distribution to the assetpool based on the weight of the asset pool. In some examples, valuedistribution involves issuing rewards.

Value distributed to the asset pool may be available to the one or moreasset providers with staked pool tokens. For example, the value may bein the form of reward tokens distributable to the one or more assetproviders based on their staked pool tokens.

In some examples, the asset pool and the one or more other asset poolsare in a group of asset pools associated with the DeFi protocol, e.g., agroup of asset pools registered with a farming system of or associatedwith the DeFi protocol. Value may be distributed based on the weight ofeach asset pool relative to a global weight of the group of asset pools.The weight may be a time-scaled weight.

In some examples, a method includes causing generation of the asset poolon the blockchain network and issuing of the pool tokens to theplurality of asset providers. The method may include detecting, by theone or more self-executing contracts, that the asset pool meets one ormore value distribution criteria (e.g., rewards criteria), andresponsive to detecting that the asset pool meets the one or more valuedistribution criteria, designating the asset pool as valuedistribution-eligible (e.g., rewards-eligible) on the blockchainnetwork. The value distribution criteria may include one or more of: aminimum duration of pool existence, a minimum number of asset providers,or a minimum pool value.

Where value distribution involves issuing rewards, different types ofrewards may be issued, depending on the implementation. In someexamples, the rewards comprise reward tokens, e.g., governance tokens ofthe DeFi protocol. The reward tokens may be fungible tokens usablewithin the context of the DeFi protocol. The reward tokens may, in someexamples, provide voting rights. In some examples, the pool tokens arefungible tokens (e.g., usable to redeem a share of assets in an assetpool).

The one or more self-executing contracts may be deployed so as torelease value based on a schedule, e.g., from an escrow. For example,reward tokens can be released from a reward token escrow based on adecreasing release schedule, withdraw the released reward tokens fromthe reward token escrow, and allocate at least some of the releasedreward tokens to an asset pool. The decreasing release schedule may be aschedule that generates scarcity of value, e.g., scarcity of rewardtokens. The schedule may be a halving schedule.

Systems as described herein may provide a user interface, e.g., tofacilitate interactions between users (e.g., asset providers) and a DeFiprotocol on a blockchain network. For example, the user interface may beused to transmit messages to a user, e.g., messages indicative of valuedistributed to the asset pool, value or rewards allocated to the user,performance of the asset pool, or the like. The user interface may alsoreceive instructions, such as transaction instructions, and facilitatebroadcasting of transactions to the blockchain network.

Existing yield farming systems may depend on frequent updates fromdevelopers to distribute value such as rewards, creating a potentialpoint of failure and introducing risks, such as security or transparencyrisks, or the risk of unscrupulous activities. Examples described hereinaddress or alleviate these technical hurdles through a decentralized,self-sustaining yield farming system. The system uses self-executingcontracts to automatically track performance over discrete periods,update pools weights, unlock value, and distribute value. In someexamples, the system described herein is protocol-agnostic and caneasily be integrated into various types of DeFi protocols or projects.For example, a DeFi protocol may integrate a yield farming system asdescribed herein by calling relevant functions of its self-executingcontracts, e.g., in response to a transaction being executed against anasset pool, the DeFi protocol may automatically call a function of theyield farming system to update pool weights and distribute rewards.

Examples described herein may provide a value distribution system thatis secure and sustainable for as long as its underlying blockchainnetwork continues to operate. Once the system is deployed, it mayoperate without the need for developers to perform updates or initiatedecisions, such as weight adjustments, and automatically incentivizesusers to register pools or perform transactions (e.g., by releasingrewards based on a decreasing release schedule). Examples describedherein may also provide techniques for enhancing inclusiveness, e.g., bymaking all registered asset pools with recent unrealized profitseligible to receive value based on their performance relative to otherasset pools.

When the effects in this disclosure are considered in aggregate, one ormore of the methodologies or systems described herein may obviate a needfor certain efforts or resources that otherwise would be involved inDeFi protocols or yield farming systems. Computing resources used by oneor more machines, nodes, databases, or networks may be more efficientlyutilized or even reduced, e.g., as a result of automatic orself-executing management of value distribution operations that reducesinteractions between end user computing devices and blockchain networknodes. Examples of such computing resources may include processorcycles, network traffic, memory usage, processing unit resources, datastorage capacity, power consumption, and cooling capacity.

FIG. 1 is a block diagram illustrating various layers of a DeFi system102, according to some examples. As mentioned, a “DeFi” (DecentralizedFinance) system is able, through the use of technology, to offerfinancial instruments without relying on intermediaries, such asbrokerages, exchanges, or banks. The DeFi system 102 of FIG. 1 utilizesself-executing contracts on a blockchain network, as described below.

The DeFi system 102 may include one or more layers, such as those shownin FIG. 1 . FIG. 1 shows an application layer 104, an aggregation layer106, a protocol layer 108, an asset layer 110, and a settlement layer112. One or more of the layers shown in FIG. 1 may work together orinteract to provide a comprehensive and decentralized solution.

Referring firstly to the asset layer 110, the asset layer 110 is afoundational layer of the DeFi system 102 that hosts or provides one ormore assets, such as cryptocurrencies. These assets may take the form oftokens on a blockchain network, e.g., Ethereum™ or Celo™ (bothopen-source blockchain platforms that enable self-executing contracts).The assets may thus be referred to, at least in some cases, as tokenizedassets. Various asset types may be supported, e.g., native blockchainassets such as ETH (in the case of Ethereum™), stablecoins, tokensrepresenting real-world commodities (e.g., gold), or tokens tied to aparticular DeFi project. Tokens may include fungible and/or non-fungibletokens.

Turning to the protocol layer 108, this layer comprises self-executingcontracts. A self-executing contract, e.g., “smart contract,” may setrules or guidelines for how assets can be mobilized, traded, lent,borrowed, staked, or the like. Self-executing contracts may also setrules or guidelines for how value is distributed or rewards are issued,e.g., in a yield farming system comprising multiple asset pools. A DeFiprotocol, such as one of the example protocols mentioned above, may besituated in the protocol layer 108. A DeFi protocol may have a specificset of rules and logic, articulated and enforced within its respectiveself-executing contracts. The protocol layer 108 may thus enablefunctionality relating to, for example, asset management 114, exchange116, lending 118, or derivatives 120, as shown in FIG. 1 .

The application layer 104 facilitates user interaction with one or moreDeFi protocols. The application layer 104 may be a user-facing layerthat delivers a user interface (e.g., a graphical user interface of asoftware application or web application). The application layer 104 maysimplify tasks such as swapping tokens, investing assets, providingliquidity, borrowing assets, or redeeming rewards, all of which mayrequire a degree of interaction with the underlying protocols.

The DeFi system 102 may include the aggregation layer 106 to aggregatedata or functionality, e.g., from various protocols. The aggregationlayer 106 may include services that channel transactions via multipleprotocols, e.g., to provide reduced fees or specific functionality. Theaggregation layer 106 may implement aspects of a yield farming system orplatform, e.g., to migrate assets between protocols to optimize returns.

Referring finally to the settlement layer 112, in some examples, thesettlement layer 112 refers to the blockchain network. For example, thesettlement layer 112 may comprise the underlying blockchain of a DeFiprotocol, where self-executing contracts are deployed, and wheretransactions are reconciled and recorded. For example, the Ethereumυblockchain or Celo™ blockchain may serve as the settlement layer 112.The settlement layer 112 provides a decentralized and secure method toauthenticate and chronicle all transactions. The settlement layer 112enables automatic execution of self-executing contracts, e.g., inresponse to the fulfilment of predetermined conditions or in response tothe calling of functions within those self-executing contracts.

The one or more layers of the DeFi system 102 may contribute to adecentralized and transparent ecosystem. This may, for example, enablefeatures such as lending or borrowing funds directly, speculating onprice movements of assets using derivatives, trading ofcryptocurrencies, insuring against risks, and earning interest insavings-like accounts, without traditional intermediaries.

It is noted that a layered architecture is shown in FIG. 1 primarily forillustrative purposes. Interactions between “layers” may be complex,e.g., the application layer 104 may interact with the asset layer 110directly or via one or more other layers. The DeFi system 102 can beimplemented using a combination of software and hardware components. Twoor more of the layers of FIG. 1 may be combined into a single layer, andthe functions described herein for a single layer may be subdividedamong multiple layers. Furthermore, according to various examples,aspects of a layer described herein may be performed by a singlemachine, database, or device, or may be distributed across multiplemachines, databases, or devices, e.g., interconnected through a network.

FIG. 2 is a diagrammatic representation of a networked computingenvironment 200 in which aspects of some examples of the presentdisclosure may be implemented or deployed. One or more servers in aserver system 204 provide server-side functionality via one or morenetworks 202 to a networked device, in the example form of a user device206 that is accessed by a user 208. The user 208 may be a user of a DeFiprotocol, e.g., an asset provider in one or more asset pools of the DeFiprotocol, or a user that otherwise interacts with self-executingcontracts of the DeFi protocol to perform transactions.

A web client 212 (e.g., a browser) or a programmatic client 210 (e.g.,an “app”) may be hosted and executed on the user device 206. AnApplication Program Interface (API) server 220 and a web server 222provide respective programmatic and web interfaces to components of theserver system 204. A specific application server 218 hosts a deploymentsystem 224 and an interface system 226, each of which includescomponents, modules, or applications.

The user device 206 can communicate with the application server 218,e.g., via the web interface supported by the web server 222 or via theprogrammatic interface provided by the API server 220. It will beappreciated that, although only a single user device 206 is shown inFIG. 2 , a plurality of user devices may be communicatively coupled tothe server system 204 in some examples. Further, while certain functionsare described herein as being performed at either the user device 206(e.g., web client 212 or programmatic client 210) or the server system204, the location of certain functionality either within the user device206 or the server system 204 may be a design choice. In some examples,particular technology and functionality may be deployed within theserver system 204. In other examples, such technology and functionalitymay be deployed within a programmatic client.

The application server 218 is communicatively coupled to databaseservers 228, facilitating access to an information storage repository ordatabase 230. In some examples, the database 230 includes storagedevices that store information to be processed or transmitted by thedeployment system 224 or by interface system 226, e.g., details ofself-executing contract or details of transactions or valuedistribution.

The application server 218 uses the deployment system 224 to deploy aset of self-executing contracts to a blockchain network 236 in order toprovide certain functionality of or in relation to a DeFi protocol orDeFi system, e.g., the DeFi system 102 of FIG. 1 . The user 208 mayinteract with the blockchain network 236 as part of a yield farmingstrategy, e.g., provide liquidity, earn value (e.g., reward tokens,assets, or cash), and stake value (e.g., reward tokens) in the DeFiprotocol.

The blockchain network 236 may be a network of computing devices orcomputing nodes (e.g., a peer-to-peer network) that stores and managesat least one blockchain. The blockchain is a list of records, calledblocks, that are cryptographically linked. In some examples, theblockchain network 236 is a Celo™ blockchain network. In some examples,the blockchain network 236 is an Ethereum™ blockchain network. Theblockchain network 236 may store blocks, calculate new blocks, processtransactions (e.g., via self-executing contracts) and the like. Examplesof self-executing contracts are described with reference to FIGS. 3-6below.

The application server 218 further accesses application data (e.g.,application data stored by the database servers 228) to provide anapplication to the user device 206 via a web interface 232 or an appinterface 234. The application may be a DeFi application, e.g., providedas part of the application layer 104 of FIG. 1 . The DeFi applicationmay facilitate user interaction with the DeFi protocol or DeFi system onthe blockchain network 236, e.g., facilitate transactions that the userwishes to perform. The user 208 may access the DeFi application using adedicated programmatic client 210 (e.g., installed on a computingdevice, such as a desktop computer or a portable computing device), withsome functionality being provided client-side and other functionalityprovided server-side. Some or all functionality of the DeFi applicationmay thus be deployed by a programmatic client 210 executing on the userdevice 206.

In some examples, the user 208 may either directly access the blockchainnetwork 236 (e.g., by calling self-executing contract functions directlyvia the network 202) via the network 202 or utilize functionality of theDeFi application to facilitate or simplify accessing of the blockchainnetwork 236. The interface system 226 may provide a GUI via the appinterface 234 or the web interface 232 that enables the user 208 toprovide input data and view or receive outputs generated by theinterface system 226. For example, the GUI may enable the user 208 torequest trades (e.g., swapping tokens or providing liquidity) and toreceive messages with information, such as information relating to anasset pool in which the user 208 is an asset provider, e.g., rewardsissued to the asset pool.

In some examples, the DeFi application is designed to “abstract away”certain technical aspects of blockchain transactions, making it easierfor users to interact with a DeFi protocol. For example, the DeFiapplication may simplify token selection, transaction approval,liquidity provision, investments, or gas fees, and may make it easierfor users to view data such as transaction status, investment status, orrewards status.

To access the DeFi application provided by the interface system 226, theuser 208 may create an account with an entity associated with the serversystem 204, e.g., a service provider (or access an existing account withthe entity). The user 208 may use account credentials to access the appinterface 234 or web interface 232 (via a suitable web browser) andrequest access to the DeFi application.

The DeFi application may integrate with a wallet that facilitatestransactions on the blockchain network 236. Alternatively oradditionally, the user may have a wallet running on the user device 206.The wallet may be used, for example, to manage and store private keyssecurely. In some examples, when a transaction is initiated on the GUIof the interface system 226, the wallet signs the transaction with theprivate key. This signed transaction provides cryptographic proof thatthe transaction is authorized by the holder of the wallet withoutrevealing the private key itself. Once a transaction is signed, it maybe propagated through the blockchain network 236 via nodes in theblockchain network 236. The transaction may be in a pending stage atfirst, after which it may be picked by a miner or validation andincluded in a next block. When a transaction is included in a block, therelevant self-executing contract on the blockchain network 236 carriesout the instruction set in the transaction. For instance, in the case ofa token swap, the self-executing contract ensures that the swap happensat an agreed rate, transferring tokens between the relevant addresses.The wallet may then update a balance and transaction state, which may bereflected on the GUI of the DeFi application.

One or more of the application server 218, the database servers 228, theAPI server 220, and the web server 222 may each be implemented in acomputer system (e.g., a personal computer, a tablet computer, or amobile phone), in whole or in part, as described below with respect toFIG. 8 . In some examples, third-party applications, such as athird-party application 216 executing on a third-party server 214, cancommunicate with the application server 218 via the programmaticinterface provided by the API server 220. For example, a third-partyapplication may support one or more features or functions on a websiteor platform hosted by a third party, or may perform methodologiesdescribed herein and provide input or output information to theapplication server 218 for further processing or publication. Forexample, the third-party application 216 may be an asset managementapplication that utilizes the DeFi protocol implemented on theblockchain network 236. The asset management application may sendcertain data to the application server 218, e.g., details of userinvestments and transactions, and receive certain data from theapplication server 218, e.g., details of user transactions or valuedistribution.

The network 202 may be any network that enables communication between oramong machines, databases, and devices. Accordingly, the network 202 maybe a wired network, a wireless network (e.g., a mobile or cellularnetwork), or any suitable combination thereof The network 202 mayinclude one or more portions that constitute a private network, a publicnetwork (e.g., the Internet), or any suitable combination thereof.

Any one or more of the components (e.g., systems or modules) describedherein may be implemented using hardware (e.g., a processor of amachine) or a combination of hardware and software. For example, anycomponent described herein may configure a processor to perform theoperations described herein for that component. Moreover, any two ormore of these components may be combined into a single component, andthe functions described herein for a single component may be subdividedamong multiple components. Furthermore, according to various examples,components described herein as being implemented within a singlemachine, database, or device may be distributed across multiplemachines, databases, or devices.

FIG. 3 is a diagram 300 illustrating the deployment of a plurality ofself-executing contracts 302 to the blockchain network 236 of FIG. 2 toprovide value distribution and other functionality in a DeFi protocol,according to some examples. The self-executing contracts 302 may bedeployed by the deployment system 224 of FIG. 2 and this configurationis illustrated in FIG. 3 .

The self-executing contracts 302 are configured to perform valuedistribution through the issuing of rewards, such as reward tokens.However, it will be appreciated that similar contracts or techniques maybe employed for other types of value distribution, such as interestpayments, asset allocations, fees, dividends, cash, airdrops to walletaddresses, non-fungible token (NFT) rewards, or the like.

The self-executing contracts 302 are shown to include the followinginternal contracts 304: a pool manager contract 306, a staking rewardsfactory contract 308, a staking rewards contract 310, a release schedulecontract 312, and a release escrow contract 314. The self-executingcontracts 302 are shown to further include an external contract 316 inthe example form of a pool contract 318. In some examples, the internalcontracts 304 are self-executing contracts associated with a yieldfarming system or value distribution system, while the external contract316 is a self-executing contract of a DeFi protocol that integrates theyield farming or value distribution system into the DeFi protocol, e.g.,a liquidity pool protocol or an asset management protocol.

Referring firstly to the pool manager contract 306, in some examples,the pool manager contract 306 may be referred to as the “main contract”of the internal contracts 304. The pool manager contract 306 may beresponsible for one or more of: generating or registering asset pools onthe blockchain network 236, marking pools as eligible to receive rewards(e.g., after they meet rewards criteria), updating a pool weight eachtime a state of an asset pool is updated (e.g., through an externaltransaction conducted against the asset pool), and withdrawing unlockedor released reward tokens from a reward token escrow.

In some examples, the pool manager contract 306 includes predeterminedalgorithms, calculations and/or formulas for performing certainfunctions, such as tracking asset pool performance and updating poolweights. The pool manager contract 306 may define a predeterminedperformance metric and/or a predetermined weight metric, as describedfurther below.

The staking rewards factory contract 308 is an example of a factorycontract and is responsible for deploying the staking rewards contract310 in response to the registering or generation of an asset pool. Assetproviders can deposit assets in the asset pool and receive pool tokensthat represent their respective shares of the assets in the asset pool.

The staking rewards contract 310 is a rewards contract that is anexample of a value distribution contract, and is designed to represent a“farm.” The staking rewards contract 310 is associated with an assetpool and receives rewards (if any) from the pool manager contract 306.Users, e.g., asset providers, can stake pool tokens in this contract toearn a share of the rewards of the asset pool, proportional to theirrespective stakes. In some examples, the farm receives rewards wheneverthe state of its associated asset pool is updated, e.g., when anexternal transaction, such as depositing or withdrawing, is performedagainst the relevant asset pool. In other examples, the farm onlyreceives the relevant rewards when a user initiates a claim, e.g., arewards claim.

As mentioned, in some examples, the rewards allocated to an asset poolmay include reward tokens, e.g., governance tokens of the relevant DeFiprotocol. In some examples, the number of reward tokens available for auser can be calculated using the formula below, where x is the number ofreward tokens available for the user, buser is the number of pool tokensthe user has deposited in the farm, r is the current reward per tokenstored, r_(user) is the reward per token stored when the user lastclaimed rewards, and x_(user) is the number of unclaimed reward tokensthe user accumulated when they last deposited or withdrew from the farm.The formula below may be built into the staking rewards contract 310.

x=(b _(user)*(r−r _(user)))+x _(user)

In some examples, a global reward per token stored is defined so as tobe strictly increasing to prevent unclaimed user rewards from decreasingwhenever the total supply of deposited pool tokens changes. Whenever auser deposits or withdraws from the farm, r_(user) is set to r andpending rewards are added to x_(user) to prevent the change in thenumber of deposited pool tokens from affecting the pending rewards ofthe user. Whenever a user claims rewards, x_(user) is set to zero andr_(user) is set to r.

Referring now to the release schedule contract 312, as mentioned, rewardtokens may be released according to a decreasing release schedule. Therelease schedule contract 312 may be used for calculating the number ofreward tokens unlocked based on the time elapsed since the contract wasdeployed. Tokens may be unlocked on a halving (also referred to as“halvening”) schedule. The schedule may consist of an infinite number ofcycles, each lasting a predetermined period of time, e.g., 20 weeks, 26weeks, or 32 weeks. When a halving schedule is employed, each cycledistributes half as many tokens as the previous cycle, creatingartificial scarcity for the reward tokens. It is noted, however, thatthe release schedule may be customized prior to deployment to suitrequirements.

In some examples, the reward rate can be calculated using the followingformula, where r is the reward rate, n is the number of tokensdistributed in the first cycle, i is the index of the cycle, and d isthe duration of the cycle (in seconds). The formula below may be builtinto a self-executing contract, such as the release schedule contract312.

$r = \begin{Bmatrix}{\frac{n}{2^{i - 1}*d},} & {{{if}i} > 0} \\{0,} & {{{if}i} = 0}\end{Bmatrix}$

In some examples, the available rewards can be calculated using thefollowing formula, where x is the amount of rewards available, t_(s) isthe start time of the current cycle, t_(l) is the last time rewards wereclaimed, t_(c) is the current time, and r is the reward rate calculatedpreviously. The formula below may be built into a self-executingcontract, such as the release schedule contract 312.

$x = \begin{Bmatrix}{{\left\lbrack {\left( {t_{s} - t_{l}} \right)*2r} \right\rbrack + \left\lbrack {\left( {t_{c} - t_{s}} \right)*r} \right\rbrack},} & {{{if}t_{l}} < t_{s}} \\{{\left( {t_{c} - t_{l}} \right)*r},} & {{{if}t_{l}} \geq t_{s}}\end{Bmatrix}$

The pool manager contract 306 may be configured to call the releaseescrow contract 314 to release reward tokens. In some examples, therelease escrow contract 314 acts as a reward token escrow and stores thelifetime supply of reward tokens to distribute. The release escrowcontract 314 uses the release schedule of the release schedule contract312 to determine how many tokens to unlock at any given time. In someexamples, the pool manager contract 306 automatically calls the releaseescrow contract 314 whenever the weight of an asset pool is updated (asfurther described below) or a user claims rewards (as also furtherdescribed below).

The external contract 316, or multiple external contracts, may depend onthe implementation. In the example of FIG. 3 , the external contract 316is the pool contract 318, which represents a decentralized hedge fundthat is part of an external asset management protocol. The assetmanagement protocol integrates the farming or value distribution systemby, for example, calling an “update pool weight” function of the poolmanager contract 306 in response to a user depositing or withdrawingfrom an asset pool, or in response to the owner of an asset poolexecuting a transaction on behalf of the asset pool.

In some examples, when registering an asset pool with the farming orvalue distribution system, a transaction is initiated by the poolcontract 318 to call a “register pool” function of the pool managercontract 306. Initially, an asset pool may not be eligible for rewards.However, and as described further below, the Average Price Change (APC)and/or unrealized profits may be tracked per period to ensure that theweight of an asset pool can be calculated after it is marked aseligible.

An asset pool may be required to meet one or more value distributioncriteria, e.g., rewards criteria. For example, the asset pool may berequired to meet one of the following rewards criteria: a minimumduration of pool existence (e.g., 30 days), a minimum number of assetproviders (e.g., 10 unique investors), or a minimum pool value (e.g.,$1000). Once the asset pool meets one or more of the value distributioncriteria, this may be detected by the pool contract 318, and the poolcontract 318 automatically initiates a transaction on the blockchainnetwork 236 to mark the asset pool as value distribution-eligible (e.g.,rewards-eligible).

To integrate the farming or value distribution system provided by theinternal contracts 304 into a DeFi protocol, the internal contracts 304are deployed to the blockchain network 236 and the lifetime supply ofreward tokens are transferred to the release escrow contract 314, e.g.,before a start time provided in the release schedule contract 312. Inthe DeFi protocol that integrates the internal contracts 304, a functionthat creates an asset pool may, for example, call a pool registrationfunction (e.g., “PoolManager.registerPool” function of the pool managercontract 306) as a last statement. Further, each function that allowsusers to interact with an asset pool (e.g., deposit, withdraw, or exit)may, for example, call a pool weight updating function (e.g.,“PoolManager.updateWeight()” function of the pool manager contract 306)as a last statement. Further, a suitable function may wrap a valuedistribution-eligible marking function (e.g.,“PoolManager.markAsEligible()” function of the pool manager contract306) that is then called once a pool is registered.

The self-executing contracts shown in FIG. 3 are shown to illustratecertain examples and are not intended to be restrictive examples. It isnoted that, in some examples, two or more of the self-executingcontracts shown in FIG. 3 may be combined into a single contract, andfunctions described herein for a single contract may be subdivided amongmultiple contracts. For example, in other cases, the internal contracts304 may include separate self-executing contracts for one or more of:determining asset pool weights, tracking asset pool performance,receiving rewards, or assigning rewards.

Main contracts, e.g., contracts that are not deployed by factorycontracts, may, for example, be deployed using the “Ethers” Javascriptlibrary. “Ethers” is a Javascript library that allows interacting withthe Ethereum™ blockchain from Javascript applications, and it can beused to deploy self-executing contracts. A contract may be deployed froma one-time script, e.g., a script that runs once to deploy eachcontract.

FIG. 4 is a diagram 400 showing a plurality of users in the example formof asset providers 412, 414, 416, 418, and 420. Each of the assetproviders 412, 414, 416, 418, and 420 has a user device 402, 404, 406,408, 410. One or more of the user devices 402, 404, 406, 408, 410 may besimilar to the user device 206 of FIG. 2 .

Each asset provider 412, 414, 416, 418, and 420 uses their respectiveuser device 402, 404, 406, 408, 410 to access the self-executingcontracts 302 of FIG. 3 after the self-executing contracts 302 aredeployed to the blockchain network 236. As depicted in FIG. 4 , theasset providers 412, 414, 416, 418, and 420 can access the blockchainnetwork 236 directly or can use the interface system 226, e.g., the DeFiapplication described with reference to FIG. 2 , to facilitate orsimplify performing transactions.

FIG. 4 also shows a plurality of asset pools 422, 424, 426. The assetproviders 412, 414, 416, 418, and 420 may perform transactions againstone or more of the asset pools 422, 424, 426, e.g., the asset provider412 may have provided assets to provide liquidity or investment into theasset pool 422, and may perform transactions against the asset pool 422by interacting with the self-executing contracts 302 on the blockchainnetwork 236.

As mentioned, the relevant DeFi protocol may integrate the internalcontracts 304 to provide various functionality, including stakingrewards. To this end, when the asset pools 422, 424, 426 becomeregistered with the yield farming system on the blockchain network 236,a staking rewards contract 310 is generated for each asset pools 422,424, 426 to define respective farms 428, 430, 432.

In some examples, the DeFi protocol is an asset management protocol. Insuch cases, the asset provider 412 receives pool tokens representingtheir share of the assets invested in the asset pool 422. By integratingthe self-executing contracts 302 into the asset management protocol, theasset management protocol receives the “farming” functionality describedwith reference to FIG. 3 . For example, the staking rewards contract 310generates a staking rewards contract associated with the asset pool 422to define the farm 428. The asset provider 412 can then stake the pooltokens against the asset pool 422 by adding or assigning them in thestaking rewards contract (and thus the farm 428). In this case, value isdistributed as follows: the rewards contract receives reward tokensissued based on the performance of the asset pool 422 and the assetprovider 412 becomes entitled to a proportional share of the rewardtokens.

The farming system may execute predetermined metrics, such asperformance and weight metrics, to track performance and update weights,as described further below. The decentralized and self-sustainingconfiguration of the yield farming system, according to some examples,allows a value distribution process or protocol to continue operating asintended automatically and without requiring manual (e.g., developer)intervention, while ensuring that the criteria used for aspects such asselecting eligible pools and distributing rewards is strictly adheredto.

Referring now to FIG. 5 , a method 500 is shown for deployingself-executing contracts to a blockchain network to register, track theperformance of, and/or distribute value to asset pools of a DeFiprotocol, according to some examples. By way of example and notlimitation, aspects of the method 500 may be performed by theself-executing contracts, modules, components, systems, or devices shownin FIGS. 1-4 . Accordingly, while reference is made to some of theseself-executing contracts, modules, components, systems, or devicesbelow, it will be appreciated that at least some operations of FIG. 5may also be performed by other self-executing contracts, modules,components, systems, or devices.

Again, while the method 500 of FIG. 5 is described with reference to theissuing of rewards in the form of tokens, it will be appreciated thatsimilar contracts or techniques may be employed for other types of valuedistribution, such as interest payments, asset allocations, fees,dividends, cash, airdrops to wallet addresses, NFT rewards, or the like.

The method 500 commences at opening loop element 502, and proceeds tooperation 504, where a plurality of self-executing contracts, e.g., theself-executing contracts 302 of FIG. 3 , are deployed to a blockchainnetwork, e.g., the blockchain network 236 of FIG. 2 . As mentioned, theinternal contracts 304 may be used to integrate a yield farming systemwith a DeFi protocol, e.g., an asset management protocol. For example,the DeFi protocol may run the asset pools 422, 424, 426 shown in FIG. 4and the yield farming system may be “plugged in” to the DeFi protocol asdescribed above. In other examples, the operation 504 may involvedeploying self-executing contracts governing both the underlying DeFiprotocol and its farming or value distribution system.

At operation 506, the asset pools 422, 424, 426 are registered with theyield farming system, e.g., using the pool manager contract 306.Responsive to registration, the staking rewards factory contract 308generates a staking rewards contract 310 for each of the asset pools422, 424, 426 to generate the farms 428, 430, 432. Users, e.g., assetproviders, are able to stake pool tokens against associated asset pools,and the yield farming system receives, through each relevant stakingrewards contract 310, an indication of the staking of pool tokens(operation 508).

At operation 510, the staking rewards contract 310 for each asset poolgenerates staking data. The staking data may be stored on the blockchainnetwork 236, e.g., in the respective farms 428, 430, 432, to indicateeach user's stake or share in rewards issued to the relevant asset pool.The staking rewards contract 310 may continuously update the stakingdata over time. When a user executes a transaction to redeem rewards,the staking data is used to determine the rewards to which the user isentitled.

As mentioned, the yield farming system tracks the performance of theasset pools. Specifically, in some examples, the performance of aparticular registered asset pool is tracked relative to the performanceof other registered asset pools using a sliding time window and apredetermined performance metric (operation 512).

In some examples, performance tracking is effected through global statevariables in the pool manager contract 306. For example, a variable oftype “mapping (pool address=>mapping (period index=>price)” can storeeach pool's price for each period index. Similar variables may be usedto store other information for each pool, such as weight, duration, APC,or the like. These variables may be updated whenever an update weightfunction, such as “PoolManager.updateWeight()” is called.

Using sliding time periods, e.g., starting from the time when the systemwas deployed, can improve tracking of pool performance over time andhelp prevent malicious actors. For example, the use of sliding (e.g.,forward-moving) periods can filter out inactive asset pools. The yieldfarming system may, in some examples, utilize a sliding time window of apredetermined duration to track asset pool performance. For example, thesliding time window may be a 14-day period. The sliding time window maybe used together with another, previous “sliding” time period to enablea comparison with past performance, as described below.

In some examples, the sliding time window referred to above is a secondperiod in which a state of the asset pool was updated, and thepredetermined performance metric tracks the performance of the assetpool by comparing the performance of the asset pool in the second periodto the performance of the asset pool in a first period (prior to thesecond period) in which the state of the asset pool was also updated.Both the first period and the second period may have a predeterminedduration, e.g., both may be a 14-day period.

In some examples, the second period is a “latest recorded period” andthe first period is a “previous recorded period.” The latest recordedperiod refers to the most recent period in which the pool was updated.The pool may be deemed “updated” if a predetermined transaction isperformed against the pool (or affecting the pool in some way). Theprevious recorded period refers to the most recent period prior to thelatest recorded period in which the pool was updated. In cases where anasset pool has only been updated in one period, the first period and thesecond period may be the same period.

Accordingly, in some cases, the yield farming system implemented by theself-executing contracts 302 keeps track of two discrete periods foreach registered asset pool. A pool period index can be calculated usingthe formula below, in which i is pool period index, t_(c) is currenttime, t_(s) is starting time, and d is the period duration. This formulamay be incorporated into one of the self-executing contracts 302.

i=(t _(c) −t _(s))/d

The starting timestamp of a period can be calculated using the formulabelow, in which t_(i) is the starting timestamp of period “i” and theother symbols bear the same meanings as in the pool period index formulaabove. This formula may be incorporated into one of the self-executingcontracts 302.

t _(i) =t _(s)+(i*d)

The use of discrete and moving pool periods when calculating poolperformance and pool weight may allow pools that outperform over recentperiods to receive value (e.g., rewards) regardless of their longer-termperformance, e.g., lifetime performance. Further, the sliding poolperiods may ensure that brief periods of outperformance “fade away” overtime, incentivizing consistent outperformance.

In some examples, the predetermined performance metric comprises anAverage Price Change (APC) metric. In such cases, performance of theasset pool is tracked by determining an APC associated with the assetpool between the first period to the second period. The formula belowillustrates how APC can be calculated for an asset pool to comparepercentage change in pool token price (which is used downstream whencalculating pool weight), according to some examples. In the formulabelow, APC tracks the current pool token price in the current period(e.g., the second period referred to above) versus the last recordedpool token price in the latest period before the current period in whichthe pool was updated (e.g., the first period referred to above). In theformula, p is the current pool token price in the current period, p_(i)is the last recorded pool token price in the latest period before thecurrent period, t is the index of the current period, and t_(i) is theindex of the latest period before the current period. This formula maybe incorporated into one of the self-executing contracts 302, e.g., thepool manager contract 306.

${APC} = \frac{1000*\left( {p - p_{i}} \right)}{p_{i}*{\max\left( {1,{t - t_{i}}} \right)}}$

It will be noted that APC is scaled by a factor of 1000 to preservefractional percent changes, since, at least in some examples, fractionalvalues may not be allowed in self-executing contracts. For example, a100% price increase over two periods would result in an APC of 1000, anda 0.1% price increase over two periods would result in an APC of 1. The“max” function is used to account for the edge case where t=t_(i) whenthe current period is the first period, which would lead to division byzero. In this case, the value is hard-coded to one.

It is noted that, in some examples, the index of the first period is notnecessarily the index immediately preceding the index of the secondperiod. For instance, if the current period is at index 5 and the assetpool was last updated in period 1, then the first period index would be1 (and not 4). In this way, the farming system may account forinactivity between two periods while ensuring that a pool's change intoken price can be calculated.

In some examples, the use of APC may be preferable to techniques such aslifetime return. For example, when using lifetime return, the weight ofa pool (as described further below) may remain at zero until there is apositive lifetime return. This may result in technical challenges, e.g.,during an unfavorable market, rendering the farming system inoperable orineffective. Furthermore, using APC may prevent asset pools withrelatively inflated lifetime returns (which may result from an excessiverisk that paid off) from monopolizing global weight for more than alimited period, e.g., the two periods described above.

Prior to updating the weight of an asset pool, the yield farming systemmay update the available rewards associated with the asset pool andwithdraw unlocked (e.g., released) reward tokens from the release escrowcontract 314 (shown in FIG. 3 ). Unlocked reward tokens may be withdrawnon behalf of all asset pools registered in the yield farming system. Theexample algorithm entitled “Algorithm 1” below provides a non-limitingexample of an algorithm that may be automatically implemented, e.g., bythe pool manager contract 306, to update the rewards of an asset pool.

Example Algorithm 1: Updating a Pool's Rewards

1: r₀ ← r 2: r ← rewardPerToken( ) 3: if r₀ = r andreleaseEscrow.hasStarted( ) then 4:  Transfer unlocked tokens from theReleaseEscrow contract to the  PoolManager contract 5:  Transferunlocked tokens from the PoolManager contract to the  dedicatedrecipient 6: end if 7: lastUpdateTime ← currentTime 8: rewards[pool] ←earned(pool) 9: poolRewardPerTokenStored[pool] ← r

In Algorithm 1, operation 2 calculates a new global reward per tokenstored based on a current global scaled weight (described below) and theavailable rewards in the release schedule. Operation 3 compares theinitial global reward per token stored to the new global reward pertoken stored to check whether the current global scaled weight is zero.If this occurs after the release schedule has started, then the unlockedreward tokens may be sent to a dedicated recipient, e.g., to avoidgetting lost, since asset pools may not earn rewards when the totalweight is zero. Operation 8 updates the accumulated rewards of the assetpool to ensure that they do not decrease when the weight of the pool issubsequently changed. Operation 9 sets the reward per token stored ofthe asset pool to the global reward per token stored such that the assetpool has zero pending rewards. This may be performed to prevent “doublecounting,” e.g., since any additional rewards earned since a last updatewould already be accounted for in operation 8.

Turning now to the updating of the weight of the asset pool, asmentioned, in some examples, the weight of the asset pool is updated byassessing performance relative to other asset pools (operation 514). Thepredetermined weight metric may determine the weight of the asset poolbased on the APC associated with the asset pool relative to an APCassociated with a group of asset pools, as described further below. Insome examples, the weight of a pool may be updated each time a specifictransaction occurs. For example, when a predetermined transaction isperformed, the DeFi protocol may pass relevant data (e.g., total valueof the asset pool and performance of the asset pool) into a weightupdating function of the pool manager contract 306.

The formula below shows how the weight of a pool may be determined,according to some examples. The formula below is intended to make allpools with positive weight eligible for rewards, while allocating morerewards to outperforming pools. More specifically, the weight of anasset pool is based on the APC of the pool (as described above) relativeto an average APC across all rewards-eligible pools registered with theyield farming system. All pools with an APC that is greater than zero(e.g., any amount of unrealized profits over the second period or thefirst period) has a positive weight and will thus be valuedistribution-eligible, e.g., eligible for rewards. Pools performingbelow average will still have a positive weight, but the weight is lowerthan it would be if the same pool's performance were above average. Inthe formula below, p is the pool's unrealized profits, APC is as definedabove for the particular asset pool, and aAPC is the average APC acrossall pools in the farming system that meet the relevant minimum criteria.This formula may be incorporated into one of the self-executingcontracts 302, e.g., the pool manager contract 306. In this context, theterm “unrealized profits” refers to the current value (e.g., dollarvalue) of the pool minus the total value (e.g., dollar value) of userdeposits into the pool. The value of user deposits acts as a “costbasis,” and is calculated at the time of deposit and does not changewith fluctuations in asset price.

$w = \begin{Bmatrix}{{p*\sqrt{{APC} - {aAPC} + 1}},} & {{{if}{APC}} \geq {aPC}} \\{\frac{p*\log_{2}{APC}}{\sqrt{{aAPC} - {APC}}},} & {{{if}{APC}} < {aAPC}}\end{Bmatrix}$

In some examples, the average APC is calculated using the formula below,in which APC is the APC of pool i and n is the number of eligible poolsin the farming system. This formula may be incorporated into one of theself-executing contracts 302, e.g., the pool manager contract 306.

${aAPC} = \frac{{\sum}_{i}^{n}{APC}_{i}}{n}$

The example algorithm entitled “Algorithm 2” below provides anon-limiting example of an algorithm that may be automaticallyimplemented, e.g., by the pool manager contract 306, to update theweight of the asset pool. The example Algorithm 2 references Algorithm 1described above as well as Algorithm 3, which will be described below.In some examples, the weight of an asset pool is updated responsive todetecting updating of the state of the asset pool (e.g., the state maybe updated by execution of a predetermined transaction against the assetpool, such as depositing, withdrawing, exchanging, or taking a poolsnapshot).

Example Algorithm 2: Updating a Pool's Weight

 1: Use Algorithm 1  2: if u < 0 or p ≤ 0 then  3:  Throw error  4: endif  5: w₀ ← w[pool, i]  6: if currentperiodindex >poolslatestrecordedperiodindex then  7:  previous RecordedPrice_(pool) ←latestRecordedPrice_(pool)  8:  previousRecordedPeriodIndex_(pool) ← latestRecordedPeriodIndex_(pool)  9: end if 10: u_(pool) ← u 11:latestRecordPrice_(pool) ← p 12: latestRecordedPeriodIndex_(pool) ← i13: if pool is not eligible then 14:  lastUpdated_(pool) ← currentTime15:  Return early 16: end if 17: Subtract from totalWeightedAPC andtotalDuration 18: APC_(pool) ← calculateAveragePriceChange(pool) 19:lastUpdated_(pool) ← currentTime 20: Add to totalWeightedAPC andtotalDuration 21: w ← calculatePoolWeight(pool) 22: poolPeriods[pool, i]← w 23: globalPeriods_(i) ← globalPeriods_(i) − w₀ + w 24: Use Algorithm3

In Algorithm 2, Operation 1 calls Algorithm 1 to update the pool'srewards. Operations 2-4 revert the transaction if the pool has anunrealized loss (u) or the pool's token price (p) is below 0. Thesevalues are provided by the external protocol when calling the function“PoolManager.updateWeight( )” Operation 5 creates a temporary variablethat stores the pool's weight for the current period (before updating).Operations 6-9 set the pool's “previous recorded price/index” to the“latest recorded price/index” if the current period index (global) isgreater than the pool's “latest recorded period index.” This is done tokeep track of the two periods needed for calculating APC. Operation 10sets the pool's unrealized profits to the unrealized profits provided bythe external protocol. Operation 11 sets the pool's latest recordedprice to the pool token price provided by the external protocol.Operation 12 sets the pool's “latest recorded period index” to thecurrent global period index. Operations 13-16 set the pool's “lastupdated” timestamp to the current timestamp and ends the algorithm earlyif the pool is not eligible for rewards. Operation 17 subtracts thepool's time-scaled APC and duration from the “totalWeightedAPC” and“totalDuration” global variables before updating the pool's APC and“last updated” timestamp. Operation 18 sets the pool's APC to the valuecalculated using the example formula provided above. Operation 19 setsthe pool's “last updated” timestamp to the current timestamp (global).Operation 20 adds the pool's new APC and duration (number of seconds thepool has existed) to the “totalWeightedAPC” and “totalDuration” globalvariables. Operation 21 creates a temporary variable (w) that stores thepool weight calculated using the example formula provided above.Operation 22 sets the pool weight for the current period to the valuecalculated in Operation 21. Operation 23 updates the global weight forthe current period by the difference between the value calculated inOperation 21 and the value calculated in Operation 5. Operation 24 usesAlgorithm 3 to get the latest rewards.

As mentioned, updating weights may be carried out using Algorithm 2, andsuch an algorithm may be implemented on a self-executing contract, suchas an Ethereum Virtual Machine (EVM) “smart contract.”

It is noted that, in some examples, such as in the case of an EVMblockchain, the code stored in a self-executing contract is immutableand is guaranteed to execute as described in the deployed bytecodewhenever a transaction is sent to the contract.

Still referring to the method 500 of FIG. 5 , the method 500 includesdistributing value to the asset pool based on the weight of the assetpool at operation 516. In this example, and as mentioned above, valuedistribution involves issue reward tokens based on the weight of theasset pool. The method 500 may include detecting updating of a state ofthe asset pool (e.g., a transaction performed with respect to the assetpool), detecting that the asset pool is value distribution-eligible, andresponsive to detecting the updating of the state of the asset pool andthat the asset pool is value distribution-eligible, distributing valueby issuing the rewards to the asset pool.

In some examples, to determine the rewards to which a particular assetpool is entitled, the asset pool's share of global rewards must bedetermined. A pool's share of available rewards may be calculated bytaking the ratio of the pool's weight in the current period to globalweight in the current period. In some examples, to prevent weights fromstarting at zero whenever a new period starts, linear time scaling isapplied to weights in the current period (e.g., the second periodreferred to above) and the previous period (e.g., the first periodreferred to above). The time-scaled weight may be calculated using theformula below, in which w, represents the time-scaled weight, wrepresents the weight in the current period, wo represents the weight inthe previous period, t represents the current time, to represents thestart time for the current period, and d represents the period duration.This formula may be incorporated into one of the self-executingcontracts 302, e.g., the pool manager contract 306.

$w_{c} = \frac{\left\lbrack {w*\left( {t - t_{0}} \right)} \right\rbrack + \left\lbrack {w_{0}*\left( {d + t_{0} - t} \right)} \right\rbrack}{d}$

There may be an edge case where time-scaled weights are strictly lowerin the first period of the farming system, since the weights for theprevious period would be zero by default, but both pool and globalweights would be multiplied by the same scalar, so the rewarddistribution is not affected. In some examples, time scaling alsopenalizes pools that were inactive or underperforming in either thecurrent period or previous period without eliminating their share ofrewards entirely. Their rewards are reduced based on the time elapsed inthe underperforming period versus the time elapsed in the other period.

A current global scaled weight may be calculated using the formula abovefor time-scaled weight by using w as the global weight in the currentperiod (e.g., the second period referred to above), wo as the globalweight in the previous period (e.g., the first period referred toabove), t as the current timestamp, and t₀ as the starting timestamp forthe current period. After calculating the global scaled weight, thecurrent global reward per token (r) can be calculated using the formulabelow, in which r₀ is the current global reward per token stored, x isthe number of tokens unlocked in the release schedule, and w is theglobal scaled weight calculated previously. This formula may beincorporated into one of the self-executing contracts 302, e.g., thepool manager contract 306.

$r = \begin{Bmatrix}{{r_{0} + \frac{x}{w}},} & {{{if}w} > 0} \\{r_{0},} & {{{if}w} = 0}\end{Bmatrix}$

In some examples, after calculating the global reward per token storedand the global scaled weight, the relevant asset pool's scaled weightmay be calculated using the above formula with the weight of the assetpool in the current period for w and the weight of the asset pool in theprevious period for wo. When calculating the scaled weight of an assetpool and global scaled weight, wo can be set to zero in the case of thefirst period since the release escrow started.

The share of rewards for the particular asset pool may then becalculated using the formula below, in which x is the number of tokensunlocked for the pool, w is the pool's scaled weight, r is the rewardper token calculated previously, r_(pool) is the reward per token whenthe pool last claimed rewards, and x₀ is the number of tokensaccumulated when the pool last updated its weight. It is noted here thatboth the scaled pool weight and the scaled global weight are multipliedby the same scalar, and the global weight changes by delta w_(pool)whenever a pool is updated, resulting in the sum of pool weightsequaling the global weight. The formula below may be incorporated intoone of the self-executing contracts 302, e.g., the pool manager contract306.

x=(w*(r−r _(pool)))+x₀

At operation 516 of the method 500, rewards are issued to the relevantasset pool. The example algorithm entitled “Algorithm 3” below providesa non-limiting example of an algorithm that may be automaticallyimplemented, e.g., by the pool manager contract 306, to transfer pendingrewards to the farm of a pool, e.g., the farm 428 of the asset pool 422of FIG. 4 . The operations below may be triggered by the staking rewardscontract 310 of the farm 428 in response to a user claiming rewards.

Example Algorithm 3: Getting Rewards

 1: Update the pool's rewards  2: Withdraw unlocked tokens from theReleaseEscrow contract and store them in the PoolManager contract  3: x← x_(pool)  4: if x > 0 then  5:  x_(pool) ← 0  6:  Transfer x tokens tothe pool's farm  7:  if the farm's total supply = 0 then  8:   Transferpool's share of tokens to the dedicated recipient  9:  end if 10: r_(farm) ← r_(farm) + x/s_(farm) 11: end if

In Algorithm 3, Operation 1 uses Algorithm 1 to update the pool'srewards. Operation 2 calculates the protocol's pending rewards based onthe halving schedule in the release escrow contract 314 and the elapsedtime since the last claim, withdraws the calculated number of tokensfrom the release escrow contract 314, and transfers the tokens to thepool manager contract 306. Operation 3 creates a temporary variable (x)with value set to the pool's stored rewards. This is done to keep trackof the distributed reward after the stored rewards have been reset to 0.Operation 5 resets the pool's stored rewards to 0. Operations 7-9 handlethe edge case where the farm has no pool tokens deposited. In this case,rewards are transferred to the dedicated recipient (staking contract orany address the protocol owner chooses) instead of the farm. This mayprevent tokens from getting “stuck” in the contract. Operation 10updates the farm's “reward per token stored.” The symbol s_(farm)represents the farm's total supply of tokens deposited. At operation518, value can then be allocated, distributed, or transferred to a user(e.g., the asset provider 412). In this case, the user is provided withrewards based on the staking data of the asset pool. The method 500 endsat closing loop element 520.

As mentioned above, various types of value distribution criteria may beemployed, depending on the implementation or use case. Generally, if itwere too “easy” to register an asset pool and become eligible for valuedistribution, users may be more likely to take excessive risks in anattempt to obtain a higher pool weight. Excessive risk-taking may bedetrimental to investors since it may be more likely to have negativeexpected value.

Further, robust value distribution criteria may reduce the risk of asuccessful “Sybil attack” where a user, for example, creates multipleaccounts to interact with a DeFi protocol with malicious intent. In thecontext of a yield farming system, a Sybil attack could involve thecreation of multiple wallets to bypass the pool-per-user limit on a DeFiprotocol integrating the farming system. A user may take on excessiverisks on each of their pools in the hope that risk will generate largereturns for one of the pools. The pool with a large return may then havea greater weight in the farming system, leading to a higher AnnualPercentage Rate (APR) for the pool's farm, which would incentivize otherusers to invest in the pool, e.g., simply to deposit the pool tokens inthe pool's farm. To help discourage excessive risk-taking and reduce thepossibility of a Sybil attack, as well as the potential damage to a DeFiprotocol if a Sybil attack is conducted, the farming system mayintroduce one or more minimum value distribution criteria that an assetpool must meet before it can be eligible for value distribution.

For example, and as mentioned above, the following value distributioncriteria may be used:

A. Pool has existed for at least a predetermined number of days, e.g.,30 days;B. Pool has at least a predetermined number of unique assetproviders/investors, e.g., 10 unique investors; orC. Pool has at least a minimum asset value, e.g., $1000 in value.

In some examples, criterium A encourages pool managers to establish atrack record to prove that they are consistently performing well. Byhaving a track record of consistent outperformance, pool managers candemonstrate to potential investors that their strategy has positiveexpected value. It may still be possible for pool managers to takeexcessive risk and wait, for example, for 30 days without makingadditional trades to maintain an artificially high lifetime return, butthe profitable trade will not impact the pool's weight after two periodsbased on the sliding system described above. In some examples, criteriaB and C in combination could help to discourage Sybil attacks. A userwanting to bypass these requirements would need to deposit at least theminimum value (e.g., $1000) of their own funds across multiple accountsto simulate multiple unique investors. It may be unlikely that extrarewards from having a higher pool weight would outweigh the investedvalue at risk.

Turning to FIG. 6 , a method 600 is shown to facilitate user interactionwith an asset pool of a DeFi protocol, according to some examples. Byway of example and not limitation, aspects of the method 600 may beperformed by the self-executing contracts, modules, components, systems,or devices shown in FIGS. 1-4 . Accordingly, while reference is made tosome of these self-executing contracts, modules, components, systems, ordevices below, it will be appreciated that at least some operations ofFIG. 6 may also be performed by other self-executing contracts, modules,components, systems, or devices.

Again, while the method 600 of FIG. 6 is described with reference to theissuing of rewards in the form of tokens, it will be appreciated thatsimilar contracts or techniques may be employed for other types of valuedistribution, such as interest payments, asset allocations, fees,dividends, cash, airdrops to wallet addresses, NFT rewards, or the like.

The method 600 commences at opening loop element 602, and proceeds tooperation 604, where the interface system 226 of FIG. 2 receives arequest for a user account. For example, the user 208 may use the appinterface 234 to request, via the user device 206, a user account withthe interface system 226. The user account may be a DeFi applicationaccount. The interface system 226 then generates an account for the user208 and stores a record of the account in the database 230 (operation606).

At operation 608, the interface system 226 receives an asset poolinstruction from the user device 206 of the user 208. For example, theuser 208 may be the asset provider 412 of FIG. 4 requesting to invest inthe asset pool 422 and/or to stake pool tokens in the farm 428associated with the asset pool 422. At operation 610, the user 208 isassociated with the asset pool 422 automatically on the blockchainnetwork 236, e.g., through operation of the pool manager contract 306 orthe staking rewards contract 310 of FIG. 3 . Further, the interfacesystem 226 may associate the user 208 with the asset pool 422 in therecord stored in the database 230.

At operation 612, the interface system 226 tracks performance of theasset pool 422 on the blockchain network 236. For example, the interfacesystem 226 may monitor the APC and the weight of the asset pool 422and/or the value distributed to the asset pool 422.

In this way, the interface system 226 can conveniently provide the user208 with information regarding the asset pool 422 or value (e.g.,rewards) available to the user 208. At operation 614, the interfacesystem 226 may transmit a message to the user device 206 (e.g., via theapp interface 234) to notify the user device 206 of value distribution,such as rewards issued or allocated to the asset pool 422, or a specificshare of the rewards that the user 208 is entitled to claim.

The user 208 may then utilize the user device 206 to transmit a claim(e.g., reward claim), and the interface system 226 may receive anotification of the claim or the intention to claim a reward (operation616). As explained, while a reward is claimed directly on the blockchainnetwork 236, the interface system 226 may abstract away some of thetechnical aspects of claiming a reward, e.g., by facilitating thetransaction through the app interface 234 (operation 618). The method600 concludes at closing loop element 620.

A reward can be claimed from a farm, e.g., from the farm 428 associatedwith the asset pool 422 of FIG. 4 , by interacting with one or more ofthe self-executing contracts 302 deployed to the blockchain network 236.The example algorithm entitled “Algorithm 4” below provides anon-limiting example of an algorithm that may be automaticallyimplemented on the blockchain network 236, e.g., responsive to a claim,to ensure that reward tokens are transferred to the user 208. Forexample, assuming that the user 208 is the asset provider 412 and haspool tokens staked in the farm 428 of FIG. 4 , the user 208 can initiatethe claim by calling a “claiming” function of the relevant stakingrewards contract 310.

Example Algorithm 4: Claiming Rewards From a Farm

 1: if pool is not marked as eligible then  2:  Throw error  3: end if 4: Withdraw unlocked tokens from the ReleaseEscrow contract on behalfof all pools  5: Transfer the pool's share of tokens to the pool's farm 6: if the farm's total supply = 0 then  7:  Transfer pool's share oftokens to the dedicated recipient  8: end if  9: r_(farm) ← r_(farm) +x/s_(farm) 10: x_(user) ← earned(user) 11: r_(user) < r_(farm) 12:Transfer x_(user) tokens to the user 13: x_(user) ← 0

In Algorithm 4, Operations 1-3 revert the transaction if the pool is noteligible for rewards. Operation 4 withdraws all pending tokens for thesystem from the release escrow contract 314 (according to the halvingschedule) and stores them in the pool manager contract 306. This keepsthe release escrow contract 314 agnostic to the pools. Operation 5calculates the pool's share of tokens and transfers them to the farm.The pool's pending rewards is set to 0 in the process. Operations 6-8handle the edge case where a pool receives rewards, but no one hasdeposited pool tokens into the pool's farm. In this case, the tokensthat would have gone to the farm are instead transferred to thededicated recipient to make sure all tokens are accounted for (tokenscould get “stuck” in the pool manager contract 306 otherwise). Thededicated recipient may for example be a staking contract, aDecentralized Autonomous Organization (DAO), or any address the protocolowner selects when deploying the system. Operation 9 updates the farm's“reward per token stored.” In operation 10, x_(user) is the user'sstored rewards, separate from the rewards calculated by the differencebetween “reward per token stored.” Setting this value to “earned(user)”ensures that updating both the global and user “reward per token stored”does not reduce the user's rewards. Operation 11 sets the user's “rewardper token stored” to the farm's “reward per token stored.” Operation 12sends the stored rewards to the user, and operation 13 clears the storedrewards to prevent double-counting.

Various strategies may be considered or implemented for addressingcertain aspects of security. When it comes to malicious actors, two maincategories may be identified in the context of an asset managementprotocol: (1) pool managers who use risky strategies across multiplepools in hopes of a high pool weight, and (2) pool managers who stayprimarily in stablecoins to obtain a high pool weight with near-zerounrealized profits.

Referring to the first category, this may include a pool manager whouses a risky strategy across multiple pools by creating a new pool foreach trade until a profitable trade is made. In this context, a “riskystrategy” is defined as a strategy where the probability of achieving aprofit target is small compared to the probability of hitting a stoploss. These strategies need to necessarily have negative expected valueto be detrimental to a farming system, as long as there are moreunprofitable trades than profitable ones. Pools with a losing trade willhave a negative return on investment (ROI) for the current period,leading to zero weight. A pool with a profitable trade will have apositive ROI for the current period, leading to a positive weight and ashare of the value distribution for the current period. Such strategiesmay possibly be detrimental to the farming system, because they may leadto a large number of inactive pools, making it challenging for potentialinvestors to find reliable pools. In addition to crowding the DeFiprotocol, these strategies may also reduce value distribution toreliable pools.

In some cases, a pool manager may be incentivized to use a riskystrategy as long as the expected value of the profitable pool's farmingrewards exceeds the total expected cost. The total expected cost of sucha strategy is the total loss across unprofitable trades minus the profitfrom the one profitable trade. Before a profitable trade is made, nunprofitable trades may be expected, as shown below, where p is theprobability of a profitable trade.

$n = \frac{1 - p}{p}$

The total expected cost could then be calculated by using the formulabelow, in which c is the total expected cost, m is the minimuminvestment per pool (e.g., in accordance with the example minimum valuedistribution criteria above), p is the percentage loss on anunprofitable trade, and p₊ is the percentage profit on a profitabletrade.

$c = {m\left\lbrack {{p_{-}\left( \frac{1 - p}{p} \right)} - p_{+}} \right\rbrack}$

The pool's share of rewards is the monetary value of the total rewardsdistributed over the current period multiplied by the ratio of thepool's weight for the current period to the global weight for theperiod. The reward rate is defined as the monetary value of rewardsdistributed per second, and is given by the formula below, in which r isthe reward rate, n is the lifetime number of reward tokens (e.g.,protocol governance tokens) that will be distributed, v is the monetaryvalue per token, i is the index of the cycle, n_(p) is the number ofperiods per cycle, and d_(p) is the duration of a period in seconds.

$r = \frac{nv}{2^{i}n_{p}d_{p}}$

The total monetary value (R) distributed per period is given by theformula below, in which r is the reward rate and d_(p) is the durationof a period in seconds.

R=rd _(p)

Substituting the above formula for R into the above formula for rprovides the following:

$R = \frac{nv}{2^{i}n_{p}}$

In this context, a pool's share of rewards is given by the followingformula, in which R_(pool) is the monetary share of rewards of the pool,w_(pool) is the weight of the pool for the current period, andW_(global) is the global weight for the current period.

$R_{pool} = \frac{{Rw}_{pool}}{w_{global}}$

Substituting the formula for R directly above with the formula forR_(pool) provides the following:

$R_{pool} = \frac{{nvw}_{pool}}{2^{i}n_{p}w_{global}}$

A Sybil attack may be considered profitable if R_(pool) is greater thanc and this can be expressed as follows:

$\frac{{nvw}_{pool}}{2^{i}{mn}_{p}{w_{global}\left\lbrack {{p_{-}\left( \frac{1 - p}{p} \right)} - p_{+}} \right\rbrack}} > 1$

From the above inequality, it is noted that the probability of asuccessful attack decreases after each cycle as long as the increase inscarcity causes the token price to increase by a factor less than two.In some examples, as more pools register with the farming system, theweight of an attacker's profitable pool will constitute a progressivelysmaller portion of the total weight, decreasing the profitability of anattack.

Referring now to the second category of malicious actors, this includespool managers who stay primarily in stablecoins and only trade a smallfraction of the pool's funds to maintain a non-zero pool weight. Thesepool managers may not be detrimental to investors, but may affect thenature of a DeFi protocol integrating the farming system, e.g., bytransforming it into a stablecoin farming protocol if many registeredpools use such a strategy.

In some cases, pools may generally be encouraged to stay invested inappreciating assets to remain competitive, but during an unfavorablemarket, for example, pools may be more likely to have a negative ROI bystaying invested in assets than by staying invested in stablecoins.Under such conditions, pool managers may opt to keep the majority ofpool funds in stablecoins and only trade a small fraction of the fundsto have non-zero unrealized profits (thus earning value, e.g., rewards,for the pool). As a new favorable market emerges, pools trading assetsother than stablecoins may then outperform pools staying in stablecoins,which may cause a migration of investors from stablecoin pools. Theweight of asset pools may increase as they receive more investments,leading to higher value distribution. Accordingly, this design maymitigate the second category as stablecoin pools may start tradingassets to remain competitive.

Four so-called “edge cases” are discussed below from a valuedistribution perspective, with reference to examples in Table 1. Theedge cases are listed below:

A. Zero eligible asset pools;B. One eligible asset pool with a loss;C. One eligible asset pool with a non-zero predetermined weight and$10,000 invested; andD. Multiple eligible pools with non-zero weights.

Calculations are made using the formulas described herein and, forsimplicity, the calculations are made with a token price of $0.01 and aweekly value distribution in the form of rewards of 1 million rewardtokens.

TABLE 1 Summary of four example edge cases Unrealized Tokens Pool TVLAPC Profits Weight per Week APR A  $10000 200  $1000 666.67 3412.4017.74% B  $15000 400  $300 2700 13820.16 47.91% C  $300000 200 $4500030000 153557.41 26.61% D $1200000 400 $18000 162000 829210.01 35.93%

In case A, since there are no eligible pools (global scaled weight iszero), 1 million reward tokens go to the farming system's dedicatedrecipient (e.g., a staking contract for the reward token). In case B,the global scaled weight is zero, because the only eligible pool in thefarming system has zero unrealized profits. As in case A, the rewardtokens will go to the dedicated recipient.

In case C, the pool will receive $10,000 worth of reward tokens perweek, for an APR of 5200%. The excessive APR will either cause thereward token price to fall or lead to an influx of investments into thepool until the APR drops. In case D, pools have varying weights, butsimilar APR despite having different TVLs (Total Value Locked). The APRfor outperforming pools is higher. It is noted that the unrealizedprofits are lower than expected for the given TVL, since users aredepositing into the pools at different times. As explained above, insome examples, a pool's weight is directly proportional to itsunrealized profits. Since the increase in weight from higher unrealizedprofits equals a decrease in a user's portion of the pool's rewards, apool's APR is unaffected by an increase in deposits.

FIG. 7 is a block diagram 700 showing a software architecture 702 for acomputing device, according to some examples. The software architecture702 may be used in conjunction with various hardware architectures, forexample, as described herein. FIG. 7 is merely a non-limitingillustration of a software architecture, and many other architecturesmay be implemented to facilitate the functionality described herein. Arepresentative hardware layer 704 is illustrated and can represent, forexample, any of the above referenced computing devices. In someexamples, the hardware layer 704 may be implemented according to thearchitecture of the computer system of FIG. 8 .

The representative hardware layer 704 comprises one or more processingunits 706 having associated executable instructions 708. Executableinstructions 708 represent the executable instructions of the softwarearchitecture 702, including implementation of the methods, modules,subsystems, and components, and so forth described herein and may alsoinclude memory and/or storage modules 710, which also have executableinstructions 708. Hardware layer 704 may also comprise other hardware asindicated by other hardware 712 and other hardware 722 which representany other hardware of the hardware layer 704, such as the other hardwareillustrated as part of the software architecture 702.

In the architecture of FIG. 7 , the software architecture 702 may beconceptualized as a stack of layers where each layer provides particularfunctionality. For example, the software architecture 702 may includelayers such as an operating system 714, libraries 716,frameworks/middleware layer 718, applications 720, and presentationlayer 744. Operationally, the applications 720 or other componentswithin the layers may invoke API calls 724 through the software stackand access a response, returned values, and so forth illustrated asmessages 726 in response to the API calls 724. The layers illustratedare representative in nature and not all software architectures have alllayers. For example, some mobile or special purpose operating systemsmay not provide a frameworks/middleware layer 718, while others mayprovide such a layer. Other software architectures may includeadditional or different layers.

The operating system 714 may manage hardware resources and providecommon services. The operating system 714 may include, for example, akernel 728, services 730, and drivers 732. The kernel 728 may act as anabstraction layer between the hardware and the other software layers.For example, the kernel 728 may be responsible for memory management,processor management (e.g., scheduling), component management,networking, security settings, and so on. The services 730 may provideother common services for the other software layers. In some examples,the services 730 include an interrupt service. The interrupt service maydetect the receipt of an interrupt and, in response, cause the softwarearchitecture 702 to pause its current processing and execute aninterrupt service routine (ISR) when an interrupt is accessed.

The drivers 732 may be responsible for controlling or interfacing withthe underlying hardware. For instance, the drivers 732 may includedisplay drivers, camera drivers, Bluetooth® drivers, flash memorydrivers, serial communication drivers (e.g., Universal Serial Bus (USB)drivers), Wi-Fi® drivers, near-field communication (NFC) drivers, audiodrivers, power management drivers, and so forth depending on thehardware configuration.

The libraries 716 may provide a common infrastructure that may beutilized by the applications 720 or other components or layers. Thelibraries 716 typically provide functionality that allows other softwaremodules to perform tasks in an easier fashion than to interface directlywith the underlying operating system 714 functionality (e.g., kernel728, services 730 or drivers 732). The libraries 716 may include systemlibraries 734 (e.g., C standard library) that may provide functions suchas memory allocation functions, string manipulation functions,mathematic functions, and the like. In addition, the libraries 716 mayinclude API libraries 736 such as media libraries (e.g., libraries tosupport presentation and manipulation of various media format such asMPEG4, H.264, MP3, AAC, AMR, JPG, PNG), graphics libraries (e.g., anOpenGL framework that may be used to render two-dimensional andthree-dimensional in a graphic content on a display), database libraries(e.g., SQLite that may provide various relational database functions),web libraries (e.g., WebKit that may provide web browsingfunctionality), and the like. The libraries 716 may also include a widevariety of other libraries 738 to provide many other APIs to theapplications 720 and other software components/modules.

The frameworks/middleware layer 718 may provide a higher-level commoninfrastructure that may be utilized by the applications 720 or othersoftware components/modules. For example, the frameworks/middlewarelayer 718 may provide various graphic user interface (GUI) functions,high-level resource management, high-level location services, and soforth. The frameworks/middleware layer 718 may provide a broad spectrumof other APIs that may be utilized by the applications 720 or othersoftware components/modules, some of which may be specific to aparticular operating system or platform.

The applications 720 include built-in applications 740 or third-partyapplications 742. Examples of representative built-in applications 740may include, but are not limited to, a contacts application, a browserapplication, a book reader application, a location application, a mediaapplication, a messaging application, or a game application. Third-partyapplications 742 may include any of the built-in applications as well asa broad assortment of other applications. In a specific example, thethird-party application 742 (e.g., an application developed using theAndroid™ or iOS™ software development kit (SDK) by an entity other thanthe vendor of the particular platform) may be mobile software running ona mobile operating system such as iOS™, Android™, Windows® Phone, orother mobile computing device operating systems. In this example, thethird-party application 742 may invoke the API calls 724 provided by themobile operating system such as operating system 714 to facilitatefunctionality described herein.

The applications 720 may utilize built in operating system functions(e.g., kernel 728, services 730 or drivers 732), libraries (e.g., systemlibraries 734, API libraries 736, and other libraries 738), andframeworks/middleware layer 718 to create user interfaces to interactwith users of the system. Alternatively, or additionally, in somesystems, interactions with a user may occur through a presentationlayer, such as presentation layer 744. In these systems, theapplication/module “logic” can be separated from the aspects of theapplication/module that interact with a user.

Some software architectures utilize virtual machines. In the example ofFIG. 7 , this is illustrated by virtual machine 748. A virtual machinecreates a software environment where applications/modules can execute asif they were executing on a hardware computing device. A virtual machineis hosted by a host operating system (operating system 714) andtypically, although not always, has a virtual machine monitor 746, whichmanages the operation of the virtual machine as well as the interfacewith the host operating system (e.g., operating system 714). A softwarearchitecture executes within the virtual machine 748 such as anoperating system 750, libraries 752, frameworks/middleware 754,applications 756 or presentation layer 758. These layers of softwarearchitecture executing within the virtual machine 748 can be the same ascorresponding layers previously described or may be different.

Certain examples are described herein as including logic or a number ofcomponents, modules, or mechanisms. Components or modules may constituteeither software components (e.g., code embodied (1) on a non-transitorymachine-readable medium or (2) in a transmission signal) orhardware-implemented components. A hardware-implemented component orhardware-implemented module is a tangible unit capable of performingcertain operations and may be configured or arranged in a certainmanner. In examples, one or more computer systems (e.g., a standalone,client, or server computer system) or one or more hardware processorsmay be configured by software (e.g., an application or applicationportion) as a hardware-implemented component or module that operates toperform certain operations as described herein.

In various examples, a hardware-implemented component may be implementedmechanically or electronically. For example, a hardware-implementedcomponent may comprise dedicated circuitry or logic that is permanentlyconfigured (e.g., as a special-purpose processor, such as a fieldprogrammable gate array (FPGA) or an application-specific integratedcircuit (ASIC)) to perform certain operations. A hardware-implementedcomponent may also comprise programmable logic or circuitry (e.g., asencompassed within a general-purpose processor or another programmableprocessor) that is temporarily configured by software to perform certainoperations. It will be appreciated that the decision to implement ahardware-implemented component mechanically, in dedicated andpermanently configured circuitry, or in temporarily configured circuitry(e.g., configured by software) may be driven by cost and timeconsiderations.

Accordingly, the term “hardware-implemented module” or“hardware-implemented component” should be understood to encompass atangible entity, be that an entity that is physically constructed,permanently configured (e.g., hardwired), or temporarily or transitorilyconfigured (e.g., programmed) to operate in a certain manner or toperform certain operations described herein. Considering examples inwhich hardware-implemented modules/components are temporarily configured(e.g., programmed), each of the hardware-implemented modules need not beconfigured or instantiated at any one instance in time. For example,where the hardware-implemented modules/components comprise, ageneral-purpose processor configured using software, the general-purposeprocessor may be configured as respective different hardware-implementedmodules/components at different times. Software may accordinglyconfigure a processor, for example, to constitute a particularhardware-implemented module/component at one instance of time and toconstitute a different hardware-implemented module/component at adifferent instance of time.

Hardware-implemented modules/components can provide information to, andreceive information from, other hardware-implemented modules/components.Accordingly, the described hardware-implemented modules/components maybe regarded as being communicatively coupled. Where multiple of suchhardware-implemented modules/components exist contemporaneously,communications may be achieved through signal transmission (e.g., overappropriate circuits and buses that connect the hardware-implementedmodules/components). In examples in which multiple hardware-implementedmodules are configured or instantiated at different times,communications between such hardware-implemented modules may beachieved, for example, through the storage and retrieval of informationin memory structures to which the multiple hardware-implementedmodules/components have access. For example, one hardware-implementedmodule/component may perform an operation, and store the output of thatoperation in a memory device to which it is communicatively coupled. Afurther hardware-implemented module/component may then, at a later time,access the memory device to retrieve and process the stored output.Hardware-implemented modules/components may also initiate communicationswith input or output devices, and can operate on a resource (e.g., acollection of information).

The various operations of example methods described herein may beperformed, at least partially, by one or more processors that aretemporarily configured (e.g., by software) or permanently configured toperform the relevant operations. Whether temporarily or permanentlyconfigured, such processors may constitute processor-implementedmodules/components that operate to perform one or more operations orfunctions. The modules referred to herein may, in some examples,comprise processor-implemented modules/components.

Similarly, the methods described herein may be at least partiallyprocessor-implemented. For example, at least some of the operations of amethod may be performed by one or more processors orprocessor-implemented modules/components. The performance of certain ofthe operations may be distributed among the one or more processors, notonly residing within a single machine, but deployed across a number ofmachines. In some examples, the processor or processors may be locatedin a single location (e.g., within a home environment, an officeenvironment, or a server farm), while in other examples the processorsmay be distributed across a number of locations.

The one or more processors may also operate to support performance ofthe relevant operations in a “cloud computing” environment or as a“software as a service (SaaS).” For example, at least some of theoperations may be performed by a group of computers (as examples ofmachines including processors), these operations being accessible via anetwork (e.g., the Internet) and via one or more appropriate interfaces(e.g., APIs).

Examples may be implemented in digital electronic circuitry, or incomputer hardware, firmware, or software, or in combinations of them.Examples may be implemented using a computer program product, e.g., acomputer program tangibly embodied in an information carrier, e.g., in amachine-readable medium for execution by, or to control the operationof, data processing apparatus, e.g., a programmable processor, acomputer, or multiple computers.

A computer program can be written in any form of programming language,including compiled or interpreted languages, and it can be deployed inany form, including as a standalone program or as a component, module,subroutine, or other unit suitable for use in a computing environment. Acomputer program can be deployed to be executed on one computer or onmultiple computers at one site or distributed across multiple sites andinterconnected by a communication network.

In examples, operations may be performed by one or more programmableprocessors executing a computer program to perform functions byoperating on input data and generating output. Method operations canalso be performed by, and apparatus of some examples may be implementedas, special purpose logic circuitry, e.g., an FPGA or an ASIC.

The computing system can include clients and servers. A client andserver are generally remote from each other and typically interactthrough a communication network. The relationship of client and serverarises by virtue of computer programs running on the respectivecomputers and having a client-server relationship to each other. Inexamples deploying a programmable computing system, it will beappreciated that both hardware and software architectures meritconsideration. Specifically, it will be appreciated that the choice ofwhether to implement certain functionality in permanently configuredhardware (e.g., an ASIC), in temporarily configured hardware (e.g., acombination of software and a programmable processor), or in acombination of permanently and temporarily configured hardware may be adesign choice. Below are set out hardware (e.g., machine) and softwarearchitectures that may be deployed, in various examples.

FIG. 8 is a block diagram of a machine in the example form of a computersystem 800 within which instructions 824 may be executed for causing themachine to perform one or more of the methodologies discussed herein. Inalternative examples, the machine operates as a standalone computingdevice or may be connected (e.g., networked) to other machines. In anetworked deployment, the machine may operate in the capacity of aserver or a client machine in server-client network environment, or as apeer machine in a peer-to-peer (or distributed) network environment. Themachine may be a personal computer (PC), a tablet PC, a set-top box(STB), a personal digital assistant (PDA), a cellular telephone, a webappliance, a network router, switch, or bridge, or any machine capableof executing instructions (sequential or otherwise) that specify actionsto be taken by that machine. Further, while only a single machine isillustrated, the term “machine” shall also be taken to include anycollection of machines (e.g., computing devices) that individually orjointly execute a set (or multiple sets) of instructions to perform anyone or more of the methodologies discussed herein.

The example computer system 800 includes a processor 802 (e.g., acentral processing unit (CPU), a graphics processing unit (GPU), orboth), a main memory 804, and a static memory 806, which communicatewith each other via a bus 808. The computer system 800 may furtherinclude a video display unit 810 (e.g., a liquid crystal display (LCD)or a cathode ray tube (CRT)). The computer system 800 also includes analphanumeric input device 812 (e.g., a keyboard or a touch-sensitivedisplay screen), a user interface navigation (or cursor control) device814 (e.g., a mouse), a storage unit 816, a signal generation device 818(e.g., a speaker), and a network interface device 820.

The storage unit 816 includes a machine-readable medium 822 on which isstored one or more sets of data structures and instructions 824 (e.g.,software) embodying or utilized by any one or more of the methodologiesor functions described herein. The instructions 824 may also reside,completely or at least partially, within the main memory 804 or withinthe processor 802 during execution thereof by the computer system 800,with the main memory 804 and the processor 802 also each constituting amachine-readable medium 822.

While the machine-readable medium 822 is shown in accordance with someexamples to be a single medium, the term “machine-readable medium” mayinclude a single medium or multiple media (e.g., a centralized ordistributed database, or associated caches and servers) that store theone or more instructions 824 or data structures. The term“machine-readable medium” shall also be taken to include any tangiblemedium that is capable of storing, encoding, or carrying instructions824 for execution by the machine and that cause the machine to performany one or more of the methodologies of the present disclosure, or thatis capable of storing, encoding, or carrying data structures utilized byor associated with such instructions 824. The term “machine-readablemedium” shall accordingly be taken to include, but not be limited to,solid-state memories, and optical and magnetic media. Specific examplesof a machine-readable medium 822 include non-volatile memory, includingby way of example semiconductor memory devices, e.g., erasableprogrammable read-only memory (EPROM), electrically erasableprogrammable read-only memory (EEPROM), and flash memory devices;magnetic disks such as internal hard disks and removable disks;magneto-optical disks; and compact disc read-only memory (CD-ROM) anddigital versatile disc read-only memory (DVD-ROM) disks. Amachine-readable medium is not a transmission medium.

The instructions 824 may further be transmitted or received over acommunications network 826 using a transmission medium. The instructions824 may be transmitted using the network interface device 820 and anyone of a number of well-known transfer protocols (e.g., hypertexttransport protocol (HTTP)). Examples of communication networks include alocal area network (LAN), a wide area network (WAN), the Internet,mobile telephone networks, plain old telephone (POTS) networks, andwireless data networks (e.g., Wi-Fi and Wi-Max networks). The term“transmission medium” shall be taken to include any intangible mediumthat is capable of storing, encoding, or carrying instructions 824 forexecution by the machine, and includes digital or analog communicationssignals or other intangible media to facilitate communication of suchsoftware.

In view of the above-described implementations of subject matter thisapplication discloses the following list of examples, wherein onefeature of an example in isolation, or more than one feature of anexample taken in combination, and, optionally, in combination with oneor more features of one or more further examples, are further examplesalso falling within the disclosure of this application.

Example 1 is a system comprising: at least one memory component thatstores instructions; and one or more processors configured by theinstructions to perform operations comprising: causing one or moreself-executing contracts deployed on a blockchain network to: associatean asset pool with a plurality of asset providers, one or more of theplurality of asset providers staking pool tokens against the asset pool,track performance of the asset pool in a sliding time window by applyinga predetermined performance metric, update a weight of the asset pool byapplying a predetermined weight metric that is based on the performanceof the asset pool, and perform value distribution to the asset poolbased on the weight of the asset pool, value distributed to the assetpool being available to the one or more asset providers with staked pooltokens; and transmitting a message that is indicative of the valuedistribution to the asset pool.

In Example 2, the subject matter of Example 1 includes, wherein theoperations further comprise: deploying the one or more self-executingcontracts to the blockchain network.

In Example 3, the subject matter of any of Examples 1-2 includes,wherein a decentralized finance protocol is implemented on theblockchain network, and the pool tokens represent respective shares ofthe plurality of asset providers in the asset pool.

In Example 4, the subject matter of any of Examples 1-3 includes, theoperations further comprising causing the one or more self-executingcontracts deployed on the blockchain network to: register the asset poolwith a yield farming system on the blockchain network.

In Example 5, the subject matter of any of Examples 1-4 includes,wherein the sliding time window has a predetermined duration.

In Example 6, the subject matter of any of Examples 1-5 includes,wherein the sliding time window is a second period in which a state ofthe asset pool was updated, and the predetermined performance metrictracks the performance of the asset pool by comparing the performance ofthe asset pool in the second period to the performance of the asset poolin a first period in which the state of the asset pool was updated, thefirst period being prior to the second period.

In Example 7, the subject matter of Example 6 includes, wherein thepredetermined performance metric comprises an Average Price Change (APC)metric, and the performance of the asset pool is tracked by determiningan APC associated with the asset pool from the first period to thesecond period.

In Example 8, the subject matter of Example 7 includes, wherein theperformance of the asset pool comprises performance of the asset poolrelative to performance of one or more other asset pools, and thepredetermined weight metric determines the weight of the asset poolbased on the APC associated with the asset pool relative to an APCassociated with a group of asset pools, the group of asset poolsincluding the asset pool and the one or more other asset pools.

In Example 9, the subject matter of any of Examples 1-8 includes, theoperations further comprising causing the one or more self-executingcontracts deployed on the blockchain network to: detect that the assetpool meets one or more value distribution criteria; and responsive todetecting that the asset pool meets the one or more value distributioncriteria, designate the asset pool as value distribution-eligible on theblockchain network.

In Example 10, the subject matter of Example 9 includes, wherein the oneor more value distribution criteria comprise at least one of: a minimumduration of pool existence; a minimum number of asset providers; or aminimum pool value.

In Example 11, the subject matter of any of Examples 9-10 includes,wherein the performing of the value distribution to the asset poolcomprises: detecting updating of a state of the asset pool; detectingthat the asset pool is value distribution-eligible; and responsive todetecting the updating of the state of the asset pool and that the assetpool is value distribution-eligible, performing the value distributionto the asset pool based on the weight of the asset pool.

In Example 12, the subject matter of Example 11 includes, wherein theweight of the asset pool is updated responsive to detecting the updatingof the state of the asset pool, and the updating of the state of theasset pool comprises execution, on the blockchain network, of apredetermined transaction against the asset pool.

In Example 13, the subject matter of any of Examples 1-12 includes,wherein the value distribution comprises issuing reward tokens, theoperations further comprising causing the one or more self-executingcontracts deployed on the blockchain network to: release reward tokensfrom a reward token escrow based on a decreasing release schedule;withdraw the released reward tokens from the reward token escrow; andallocate at least some of the released reward tokens to the asset pool.

In Example 14, the subject matter of Example 13 includes, wherein thedecreasing release schedule is a halving schedule.

In Example 15, the subject matter of any of Examples 13-14 includes,wherein the pool tokens and the reward tokens are fungible tokens.

In Example 16, the subject matter of any of Examples 13-15 includes,wherein the asset pool is associated with a decentralized financeprotocol, and the reward tokens comprise governance tokens of thedecentralized finance protocol.

In Example 17, the subject matter of any of Examples 1-16 includes, theoperations further comprising causing the one or more self-executingcontracts deployed on the blockchain network to: detect a claimoriginating from one of the plurality of asset providers; and responsiveto detecting the claim, distribute, via the blockchain network, valueassociated with the asset pool to the asset provider based on stakedpool tokens associated with the asset provider.

In Example 18, the subject matter of any of Examples 1-17 includes,wherein the one or more self-executing contracts comprise: a poolmanager contract that generates the asset pool on the blockchainnetwork; a value distribution contract associated with the asset pool,the value distribution contract receiving value distributed to the assetpool responsive to updating of a state of the asset pool, and the assetproviders being enabled to stake their respective pool tokens in thevalue distribution contract; and a factory contract that deploys thevalue distribution contract to the blockchain network responsive togeneration of the asset pool.

Example 19 is a method comprising: causing one or more self-executingcontracts deployed on a blockchain network to: associate an asset poolwith a plurality of asset providers, one or more of the plurality ofasset providers staking pool tokens against the asset pool, trackperformance of the asset pool in a sliding time window by applying apredetermined performance metric, update a weight of the asset pool byapplying a predetermined weight metric that is based on the performanceof the asset pool, and perform value distribution to the asset poolbased on the weight of the asset pool, value distributed to the assetpool being available to the one or more asset providers with staked pooltokens; and transmitting a message that is indicative of the valuedistribution to the asset pool.

Example 20 is a non-transitory computer-readable medium that storesinstructions that, when executed by one or more processors, cause theone or more processors to perform operations comprising: causing one ormore self-executing contracts deployed on a blockchain network to:associate an asset pool with a plurality of asset providers, one or moreof the plurality of asset providers staking pool tokens against theasset pool, track performance of the asset pool in a sliding time windowby applying a predetermined performance metric, update a weight of theasset pool by applying a predetermined weight metric that is based onthe performance of the asset pool, and perform value distribution to theasset pool based on the weight of the asset pool, value distributed tothe asset pool being available to the one or more asset providers withstaked pool tokens; and transmitting a message that is indicative of thevalue distribution to the asset pool.

Example 21 is at least one machine-readable medium includinginstructions that, when executed by processing circuitry, cause theprocessing circuitry to perform operations to implement any of Examples1-20.

Example 22 is an apparatus comprising means to implement any of Examples1-20. Example 23 is a system to implement any of Examples 1-20.

Example 24 is a method to implement any of Examples 1-20.

Although specific examples are described herein, it will be evident thatvarious modifications and changes may be made to these examples withoutdeparting from the broader spirit and scope of the disclosure.Accordingly, the specification and drawings are to be regarded in anillustrative rather than a restrictive sense. The accompanying drawingsthat form a part hereof show by way of illustration, and not oflimitation, specific examples in which the subject matter may bepracticed. The examples illustrated are described in sufficient detailto enable those skilled in the art to practice the teachings disclosedherein. Other examples may be utilized and derived therefrom, such thatstructural and logical substitutions and changes may be made withoutdeparting from the scope of this disclosure. This detailed description,therefore, is not to be taken in a limiting sense, and the scope ofvarious examples is defined only by the appended claims, along with thefull range of equivalents to which such claims are entitled.

Such examples of the inventive subject matter may be referred to herein,individually or collectively, by the “example” merely for convenienceand without intending to voluntarily limit the scope of this applicationto any single example or concept if more than one is in fact disclosed.Thus, although specific examples have been illustrated and describedherein, it should be appreciated that any arrangement calculated toachieve the same purpose may be substituted for the specific examplesshown. This disclosure is intended to cover any and all adaptations orvariations of various examples. Combinations of the above examples, andother examples not specifically described herein, will be apparent tothose of skill in the art upon reviewing the above description.

For example, while the overall design of the yield farming system may belargely or completely protocol-agnostic, specific metrics used can beadjusted to better suit certain protocols. For instance, the formulasused herein to illustrate performance tracking and weight determinationmay be suited to asset management protocols, but these formulas ormetrics could be adjusted to cater, for example, more specifically foran automated market maker (AMM) protocol. In an AMM protocol, a farmingsystem could assess average liquidity when determining pool weight(e.g., as opposed to the combination of unrealized profits and APC).

The various features, steps, operations, and processes described hereinmay be used independently of one another, or may be combined in variousways. All possible combinations and subcombinations are intended to fallwithin the scope of this disclosure. In addition, certain method orprocess blocks or operations may be omitted in some implementations.

Some portions of the subject matter discussed herein may be presented interms of algorithms or symbolic representations of operations on datastored as bits or binary digital signals within a machine memory (e.g.,a computer memory). Such algorithms or symbolic representations areexamples of techniques used by those of ordinary skill in the dataprocessing arts to convey the substance of their work to others skilledin the art. As used herein, an “algorithm” is a self-consistent sequenceof operations or similar processing leading to a desired result. In thiscontext, algorithms and operations involve physical manipulation ofphysical quantities. Typically, but not necessarily, such quantities maytake the form of electrical, magnetic, or optical signals capable ofbeing stored, accessed, transferred, combined, compared, or otherwisemanipulated by a machine. It is convenient at times, principally forreasons of common usage, to refer to such signals using words such as“data,” “content,” “bits,” “values,” “elements,” “symbols,”“characters,” “terms,” “numbers,” “numerals,” or the like. These words,however, are merely convenient labels and are to be associated withappropriate physical quantities.

Unless specifically stated otherwise, discussions herein using wordssuch as “processing,” “computing,” “calculating,” “determining,”“presenting,” “displaying,” or the like may refer to actions orprocesses of a machine (e.g., a computer) that manipulates or transformsdata represented as physical (e.g., electronic, magnetic, or optical)quantities within one or more memories (e.g., volatile memory,non-volatile memory, or any suitable combination thereof), registers, orother machine components that receive, store, transmit, or displayinformation. Furthermore, unless specifically stated otherwise, theterms “a” and “an” are herein used, as is common in patent documents, toinclude one or more than one instance. Finally, as used herein, theconjunction “or” refers to a non-exclusive “or,” unless specificallystated otherwise.

Unless the context clearly requires otherwise, throughout thedescription and the claims, the words “comprise,” “comprising,” and thelike are to be construed in an inclusive sense, as opposed to anexclusive or exhaustive sense, e.g., in the sense of “including, but notlimited to.” As used herein, the terms “connected,” “coupled,” or anyvariant thereof means any connection or coupling, either direct orindirect, between two or more elements; the coupling or connectionbetween the elements can be physical, logical, or a combination thereof

Additionally, the words “herein,” “above,” “below,” and words of similarimport, when used in this application, refer to this application as awhole and not to any particular portions of this application. Where thecontext permits, words using the singular or plural number may alsoinclude the plural or singular number, respectively. The word “or” inreference to a list of two or more items, covers all of the followinginterpretations of the word: any one of the items in the list, all ofthe items in the list, and any combination of the items in the list.

As used in this disclosure, phrases of the form “at least one of an A, aB, or a C,” “at least one of A, B, or C,” “at least one of A, B, and C,”and the like, should be interpreted to select at least one from thegroup that comprises “A, B, and C.” Unless explicitly stated otherwisein connection with a particular instance in this disclosure, this mannerof phrasing does not mean “at least one of A, at least one of B, and atleast one of C.” As used in this disclosure, the example “at least oneof an A, a B, or a C,” would cover any of the following selections: {A},{B}, {C}, {A, B}, {A, C}, {B, C}, and {A, B, C}.

Although some examples, e.g., those depicted in the drawings, include aparticular sequence of operations, the sequence may be altered withoutdeparting from the scope of the present disclosure. For example, some ofthe operations depicted may be performed in parallel or in a differentsequence that does not materially affect the functions as described inthe examples. In other examples, different components of an exampledevice or system that implements an example method may perform functionsat substantially the same time or in a specific sequence.

What is claimed is:
 1. A system comprising: at least one memorycomponent that stores instructions; and one or more processorsconfigured by the instructions to perform operations comprising: causingone or more self-executing contracts deployed on a blockchain networkto: associate an asset pool with a plurality of asset providers, one ormore of the plurality of asset providers staking pool tokens against theasset pool, track performance of the asset pool in a sliding time windowby applying a predetermined performance metric, update a weight of theasset pool by applying a predetermined weight metric that is based onthe performance of the asset pool, and perform value distribution to theasset pool based on the weight of the asset pool, value distributed tothe asset pool being available to the one or more asset providers withstaked pool tokens; and transmitting a message that is indicative of thevalue distribution to the asset pool.
 2. The system of claim 1, whereinthe operations further comprise: deploying the one or moreself-executing contracts to the blockchain network.
 3. The system ofclaim 1, wherein a decentralized finance protocol is implemented on theblockchain network, and the pool tokens represent respective shares ofthe plurality of asset providers in the asset pool.
 4. The system ofclaim 1, the operations further comprising causing the one or moreself-executing contracts deployed on the blockchain network to: registerthe asset pool with a yield farming system on the blockchain network. 5.The system of claim 1, wherein the sliding time window has apredetermined duration.
 6. The system of claim 1, wherein the slidingtime window is a second period in which a state of the asset pool wasupdated, and the predetermined performance metric tracks the performanceof the asset pool by comparing the performance of the asset pool in thesecond period to the performance of the asset pool in a first period inwhich the state of the asset pool was updated, the first period beingprior to the second period.
 7. The system of claim 6, wherein thepredetermined performance metric comprises an Average Price Change (APC)metric, and the performance of the asset pool is tracked by determiningan APC associated with the asset pool from the first period to thesecond period.
 8. The system of claim 7, wherein the performance of theasset pool comprises performance of the asset pool relative toperformance of one or more other asset pools, and the predeterminedweight metric determines the weight of the asset pool based on the APCassociated with the asset pool relative to an APC associated with agroup of asset pools, the group of asset pools including the asset pooland the one or more other asset pools.
 9. The system of claim 1, theoperations further comprising causing the one or more self-executingcontracts deployed on the blockchain network to: detect that the assetpool meets one or more value distribution criteria; and responsive todetecting that the asset pool meets the one or more value distributioncriteria, designate the asset pool as value distribution-eligible on theblockchain network.
 10. The system of claim 9, wherein the one or morevalue distribution criteria comprise at least one of: a minimum durationof pool existence; a minimum number of asset providers; or a minimumpool value.
 11. The system of claim 9, wherein the performing of thevalue distribution to the asset pool comprises: detecting updating of astate of the asset pool; detecting that the asset pool is valuedistribution-eligible; and responsive to detecting the updating of thestate of the asset pool and that the asset pool is valuedistribution-eligible, performing the value distribution to the assetpool based on the weight of the asset pool.
 12. The system of claim 11,wherein the weight of the asset pool is updated responsive to detectingthe updating of the state of the asset pool, and the updating of thestate of the asset pool comprises execution, on the blockchain network,of a predetermined transaction against the asset pool.
 13. The system ofclaim 1, wherein the value distribution comprises issuing reward tokens,the operations further comprising causing the one or more self-executingcontracts deployed on the blockchain network to: release reward tokensfrom a reward token escrow based on a decreasing release schedule;withdraw the released reward tokens from the reward token escrow; andallocate at least some of the released reward tokens to the asset pool.14. The system of claim 13, wherein the decreasing release schedule is ahalving schedule.
 15. The system of claim 13, wherein the pool tokensand the reward tokens are fungible tokens.
 16. The system of claim 13,wherein the asset pool is associated with a decentralized financeprotocol, and the reward tokens comprise governance tokens of thedecentralized finance protocol.
 17. The system of claim 1, theoperations further comprising causing the one or more self-executingcontracts deployed on the blockchain network to: detect a claimoriginating from one of the plurality of asset providers; and responsiveto detecting the claim, distribute, via the blockchain network, valueassociated with the asset pool to the asset provider based on stakedpool tokens associated with the asset provider.
 18. The system of claim1, wherein the one or more self-executing contracts comprise: a poolmanager contract that generates the asset pool on the blockchainnetwork; a value distribution contract associated with the asset pool,the value distribution contract receiving value distributed to the assetpool responsive to updating of a state of the asset pool, and the assetproviders being enabled to stake their respective pool tokens in thevalue distribution contract; and a factory contract that deploys thevalue distribution contract to the blockchain network responsive togeneration of the asset pool.
 19. A method comprising: causing one ormore self-executing contracts deployed on a blockchain network to:associate an asset pool with a plurality of asset providers, one or moreof the plurality of asset providers staking pool tokens against theasset pool, track performance of the asset pool in a sliding time windowby applying a predetermined performance metric, update a weight of theasset pool by applying a predetermined weight metric that is based onthe performance of the asset pool, and perform value distribution to theasset pool based on the weight of the asset pool, value distributed tothe asset pool being available to the one or more asset providers withstaked pool tokens; and transmitting a message that is indicative of thevalue distribution to the asset pool.
 20. A non-transitorycomputer-readable medium that stores instructions that, when executed byone or more processors, cause the one or more processors to performoperations comprising: causing one or more self-executing contractsdeployed on a blockchain network to: associate an asset pool with aplurality of asset providers, one or more of the plurality of assetproviders staking pool tokens against the asset pool, track performanceof the asset pool in a sliding time window by applying a predeterminedperformance metric, update a weight of the asset pool by applying apredetermined weight metric that is based on the performance of theasset pool, and perform value distribution to the asset pool based onthe weight of the asset pool, value distributed to the asset pool beingavailable to the one or more asset providers with staked pool tokens;and transmitting a message that is indicative of the value distributionto the asset pool.